Specification
Programming
Revision Control
Sourcing
Testing
30.1 서론(Introduction)
Custom Software 맞춤형 소프트웨어
많은 공정, 특히 배치 화학 제조(batch chemical manufacturing), 식품 가공(food processing), 개별 부품 제조(discrete parts manufacturing), 기계 조립 작업(mechanical assembly operations) 등은 자동화 시스템 공급업체가 제공하는 사전 정의된 기능 세트로 구성하기보다는 맞춤형 프로그래밍이 필요합니다. 맞춤형 소프트웨어 프로그래밍은 성능 달성, 일정 준수, 장기적인 지원 성공을 위해 조직과 관리가 필요한 비즈니스 프로세스입니다.
30.2 요구사항 명세서(Specification)
맞춤형 프로그래밍을 시작하기 전에 조직은 여러 가지 결정을 내려야 합니다. 가장 중요한 결정은 수행할 기능에 관한 것입니다. 자동화 기능을 수행하기 위한 방법과 원하는 결과를 정확히 설명하는 제조 명세서(manufacturing specification,이하 명세서)라는 문서를 작성해야 합니다. 프로젝트가 실패하는 경우는 대부분 무엇을 해야 하는지, 그리고 자동화 시스템이 원하는 작업을 어떻게 수행해야 하는지를 불완전하게 정의한 데서 비롯됩니다. 성공적인 프로젝트는 제조 작업의 모든 단계, 측정 항목, 제품의 흐름을 상세히 기술합니다. 실제로 제조 명세서은 완성된 제조 시퀀스가 올바르게 프로그래밍되었는지를 테스트하기 위한 기준 문서입니다.
가장 성공적인 제조 명세서 형식 중 하나는 사람이 각 단계를 수행한다고 가정하여 단계별로 작성된 지침입니다. 이 형식의 문서는 SFC(sequential function chart) 프로그래밍 방식으로 쉽게 도식화할 수 있으며, 향후 시스템을 유지보수하거나 확장, 개선할 사람들이 이해하기 쉽습니다. 또한 이 문서는 수동으로 수행해야 할 단계, 승인 절차, 자동화 공정을 감독하면서 해야 할 관찰 등을 작업자나 기계 운영자가 명확히 기술할 수 있도록 하여 통합 경로를 명확히 제공합니다. 이 문서는 이후 공정 운전 매뉴얼(operator’s manual)을 작성하는 데 필요한 자료가 됩니다.
복잡한 프로젝트에서는 소프트웨어 자체를 설계해야 합니다. 소프트웨어는 일반적으로 마스터 스케줄링 프로그램(master scheduling program), 작업을 수행하는 개별 모듈(modules), 그리고 소프트웨어가 필요로 하거나 생성하는 실시간 및 계산 데이터를 위한 데이터베이스(database)로 구성됩니다. 이러한 구조는 프로젝트를 여러 프로그래머에게 분산하여 맡길 수 있게 해줍니다. 각 프로그램 모듈은 해당 모듈이 수행할 작업, 기대되는 결과, 작업 방식, 결과 테스트 방법을 설명하는 소프트웨어 설계 명세서(SDS, software design specification)로 정의되어야 합니다. 이 기법은 모듈형 프로그래밍(modular programming)이라고 합니다.
모듈형 프로그래밍의 현대적 형태는 객체 지향 프로그래밍(object-oriented programming)입니다. C++ 또는 Java와 같은 객체 프로그래밍 언어를 사용할 경우, 각 객체(object)는 메서드(method)와 속성(attribute)을 모두 포함한 완전한 프로그래밍 모듈입니다. 일부 속성은 객체 내부에만 존재하며 외부에서는 보이지 않고 지속적이며, 다른 속성은 인스턴스화하는 프로그램에 노출됩니다. 객체 프로그래밍은 기존 프로그래밍 방식보다 데이터베이스를 통한 정보 전달에 덜 의존합니다. 객체는 각각 개별적으로 정의되고 테스트되어야 합니다.
30.3 프로그래밍(Programming)
자동화 애플리케이션을 구현하기 위해 선택되는 프로그래밍 언어는 일반적으로 9장에서 다룬 IEC 61131-3 언어 중 하나입니다. 이 유형의 프로그래밍이 해당 애플리케이션에 적합하다면, 프로그래밍의 첫 단계로 제조 명세(manufacturing specification)를 순차 기능 차트(SFC, sequential function chart)로 인코딩하는 것이 강력히 권장됩니다. SFC의 각 기능 블록은 더 상세한 SFC로 확장되어 최하위 기능 수준까지 표현될 수 있습니다. 최하위 수준의 상세 SFC 블록은 공급업체가 지원하는 LD(Ladder Diagram), FBD(Functional Block Diagram), IL, ST(Structured Text) 중 하나의 프로그래밍 언어로 코딩할 수 있습니다(9장 참조).
자동화 애플리케이션이 컴퓨터 프로그래밍 언어로 작성되는 경우는 흔하지 않지만, IEC 61131-3 언어를 지원하지 않는 컴퓨터 기반 장비를 지원하기 위해 프로그램을 작성해야 하는 경우가 있습니다. 이러한 경우에도, IEC 61131-3 언어가 적용되지 않는 저수준 SFC에 대해 커스텀 프로그래밍을 구현할 때는 SFC 절차를 사용하여 프로그램 개요를 문서화하고 계획하는 것이 중요합니다.
커스텀 프로그래밍이 필요하고 소프트웨어가 단순하지 않은 경우, 첫 단계는 사용할 프로그래밍 언어를 결정하는 것입니다. 프로그래밍 언어의 선택은 프로그램이 작성될 시스템과 실행될 시스템에서 지원하는 언어에 크게 좌우되며, 이 두 시스템이 동일하지 않을 수도 있습니다. 이 장의 목적은 프로그래밍이 필요한 경우 사용할 수 있는 지침을 제공하는 것이며, 각 프로그래밍 언어의 세부 사항은 이 책의 범위를 벗어납니다.
표 30-1은 자동화 시스템 소프트웨어 및 공정/기계 운전자가 사용할 그래픽 사용자 인터페이스를 위해 때때로 사용되는 프로그래밍 언어 목록입니다. 이 목록은 포괄적인 리스트는 아니며, 더 많은 프로그래밍 언어들이 존재하지만 참고용으로 제공됩니다.
소프트웨어 프로젝트가 위에서 언급된 프로그래밍 언어 중 하나로 계획되는 경우, 일반적으로 자동화 엔지니어의 업무 범위나 경험을 벗어납니다. 이러한 언어는 IEC 61131-3 애플리케이션 프로그래밍 언어로 통합할 수 없는 장비나, 해당 언어로는 적합하지 않은 시스템 기능을 구현해야 할 경우에만 사용해야 합니다. 이러한 프로그래밍 언어로 작성된 프로그램은 공정, 장비, 사용자 요구가 변경될 때 쉽게 수정할 수 없으며, 이러한 변경은 항상 발생합니다.
이러한 주의사항을 고려한 후, 프로그래밍 언어 선택의 장점을 논의할 수 있습니다. 먼저, 특정 운영 체제(소프트웨어가 실행될 컴퓨터의 자원을 제어하는 소프트웨어)는 특정 언어 선택을 선호합니다. 예를 들어, 운영 체제가 Windows인 경우에는 C# 또는 Visual Basic.NET을 사용하는 것이 좋습니다. 운영 체제가 Linux 또는 다른 Unix 계열일 경우에는 C++ 또는 Java가 적합한 프로그래밍 언어입니다. C 언어는 객체 지향이 아니며 유지보수가 어렵다고 여겨져 일반적으로는 구식으로 간주됩니다. C++은 객체 지향 기능이 추가된 C의 확장 버전입니다. Java는 C++의 유연성을 제공하면서도 복잡하고 오류 발생 가능성이 높은 일부 구조를 제거하여 널리 사용됩니다. 운영 환경이 웹 페이지일 경우(운영 체제와 무관하게), 일반적으로 JavaScript, HTML(hypertext markup language), 또는 XHTML(extended HTML)이 사용됩니다.
C 및 C++은 일반적으로 매우 효율적인 코드를 생성하며, 이는 디바이스 드라이버나 고속 하드웨어 또는 통신 기능을 제어하는 소프트웨어에 필요할 수 있습니다. Java, C#, Visual Basic.NET은 각각의 가상 머신(virtual machine)이 필요하며, 실행 시 언어 명령을 해석합니다. 이러한 가상 머신은 많은 애플리케이션이 해당 언어로 작성되기 때문에 상주 소프트웨어에 포함되어 있는 경우가 많지만, 머신 제어와 같은 임베디드 환경에서는 상당한 메모리를 차지합니다. 해석형 언어(interpreted language)의 코드 실행 속도는 일반적으로 C나 C++처럼 기계어로 컴파일된 프로그램보다 한 차원 느립니다. 프로그래밍 언어에 대한 최적의 선택은 존재하지 않으며, 애플리케이션에 적합한 실행 속도와 메모리 요구사항을 고려하여 가능한 한 높은 수준의 언어(표 30-1의 하단에 위치한 언어)를 사용하는 것이 바람직합니다.
가장 현대적인 프로그래밍 트렌드는 대부분의 프로그램 실행 결과를 공정/기계 운전자가 웹 페이지 기술을 통해 확인할 수 있도록 제공하는 것입니다. 인터넷 표준은 웹 페이지를 운영 체제나 사용자가 선택한 웹 브라우저와 무관하게 생성, 문서화, 검증하는 데 특히 유용합니다. 운영 환경과 독립적인 데이터 구조를 위한 웹 표준은 XML입니다. 웹 페이지는 HTML 또는 XHTML로 인코딩되어 운영 환경과 독립적으로 작동할 수 있습니다. 동적 웹 페이지(active web pages)는 서버 또는 브라우저에서 JavaScript(자바와는 관련 없으며 Sun Microsystems 소유) 또는 VBScript를 통해 프로그램을 실행해야 합니다. JavaScript는 대부분의 플랫폼에서 실행되며, VBScript는 주로 Microsoft Windows 플랫폼에서 사용됩니다. 웹 서버 측 프로그래밍은 일반적으로 Microsoft Visual Studio나 Macromedia DreamWeaver와 같은 코드 생성기를 통해 수행됩니다.
30.4 변경 이력 관리(Revision Control)
프로그래밍은 최근 몇 년간 크게 발전했지만 여전히 복잡한 작업입니다. 완벽한 프로그램을 작성하는 것은 매우 어렵고, 설령 완벽하더라도 공정이 계속 변화하기 때문에 프로그램은 반드시 변경되어야 합니다. 이는 실제 요구사항에 맞추기 위해, 그리고 잘못된 명세나 구현으로 인해 발생한 설계 및 코딩 오류를 수정하기 위해 프로그램을 자주 수정해야 함을 의미합니다. 가장 최신 버전의 프로그램을 사용하려면 적절한 변경 이력 관리 절차(revision control procedures)를 따라야 합니다.
다수의 프로그래머가 소프트웨어 모듈을 개발하고 테스트하는 대형 프로젝트에서는 각 모듈의 변경 사항을 추적하고 문서화하며, 프로젝트 관리자가 진행 상황을 보고할 수 있도록 변경 이력 관리 소프트웨어(revision control software)를 사용하는 것이 바람직합니다. 그러나 자동화 시스템에서는 이 정도 수준의 복잡도로 프로젝트를 관리하는 경우는 흔하지 않습니다.
변경 이력 관리(revision control)에서 가장 중요한 측면은 프로그램을 충분한 내부 문서화와 함께 작성하여, 이후에 쉽게 이해하고 유지보수할 수 있도록 하는 것입니다. 소프트웨어 유지보수 및 기능 개선은 원래 프로그램 모듈을 작성한 사람이 아닌 다른 사람이 수행할 가능성이 매우 높습니다. 소프트웨어 설계 명세서(software design specification)는 프로그램에서 사용할 알고리즘과 방법을 항상 제시해야 하지만, 내부 주석(comment)은 프로그램 흐름을 해당 명세서와 연결해 주어야 합니다. 효과적인 기법 중 하나는 소스 프로그램의 주석에 소프트웨어 설계 명세서의 문단을 실제로 삽입하는 것입니다.
배치 및 개별 제조 프로그램 설계에서 SFC(sequential function chart)를 사용하는 주요 이유 중 하나는 결과물인 다이어그램이 제어 로직과 흐름을 문서화해 주기 때문입니다. LD(ladder diagram)나 기타 프로그램 모듈을 SFC의 전체 블록 구조에 통합하면, 제어 로직과 흐름이 이 읽기 쉬운 그래픽 형식으로 잘 문서화됩니다. 자동화 시스템을 선택할 때는 시스템 프로그래머가 SFC 그래픽 다이어그램 도구를 사용할 수 있도록 지원하는 시스템을 우선적으로 고려하는 것이 강력히 권장됩니다. 대부분의 연속 공정 제어 시스템(DCS)은 이미 그래픽 기능 블록 다이어그램 전략 빌더를 지원합니다.
프로그래머는 프로그램을 코딩할 때 다양한 선택을 해야 합니다. 어떤 선택은 프로그램을 더 빠르고 효율적으로 실행되게 하며, 다른 선택은 유지보수자가 코드를 더 쉽게 이해할 수 있도록 합니다. 오늘날의 고속 마이크로프로세서에서는 효율적인 실행이 반드시 요구되는 경우는 드뭅니다. 가능한 경우, 프로그래머는 향후 유지보수 및 기능 개선을 수행할 사람이 구현을 명확히 이해할 수 있도록 하는 프로그래밍 구조를 선택해야 합니다.
변경 이력 관리 절차는 각 프로그램 모듈이 주석의 첫 줄과 프로그램 코드의 두 번째 줄에 실행되지 않는 텍스트 문자열로 변경 이력 코드(revision code)를 포함할 수 있도록 해야 합니다. 변경 이력 번호는 세 가지 요소로 구성됩니다: 명세 기능 변경 시에만 변경되는 최상위 번호, 각 공식 릴리스마다 변경되는 두 번째 번호, 그리고 테스트 중인 새 버전을 나타내는 작업용 문자 코드입니다. 예를 들어 “5.25.aa”는 해당 코드 모듈이 명세의 다섯 번째 버전을 구현하고 있으며, 해당 모듈의 스물다섯 번째 릴리스이며, 스물일곱 번째 테스트 버전임을 나타냅니다.
30.5 소싱(Sourcing)
누가 명세서를 작성하고 실제 구성 및 프로그래밍 작업을 수행해야 할까요? 오늘날 대부분의 사용자 기업은 자동화 시스템을 위한 원래의 설계 명세, 구성 또는 프로그래밍을 수행할 충분한 인력을 보유하고 있지 않습니다. 신규 건설 프로젝트를 수행할 때는 주요 자동화 시스템 공급업체에게 제어 루프 구성(control loop configuration)과 시스템 프로그래밍(system programming)을 모두 맡기는 것이 일반적이며, 이는 현재 “외주(outsourcing)”라고 불립니다. 이러한 외주 수행자들이 작업하는 기준이 되는 명세서는, 앞서 언급한 기법들을 활용하여 최종 사용자(end user)가 향후 제어 루프와 자동화 프로그램을 유지보수 및 개선할 수 있도록 하는 필요성을 반드시 반영해야 합니다.
외주 프로젝트에서 자주 간과되는 필수 단계가 동료 검토(peer review)입니다. 설계 및 구현의 각 주요 단계에서, 공정 및 제어 시스템에 대해 잘 알고 있는 사람들이 외주 공급업체가 준비한 명세서, 상세 계획, 심지어 프로그램 코드까지 검토해야 합니다. 동료 검토를 수행하는 사람들은 최종 사용자를 대표하며, 실제로는 이 목적을 위해 고용된 컨설턴트인 경우가 많습니다. 동료 검토는 외주 공급업체가 수행해서는 안 되며, “독립적인” 부서에 배정되었다 하더라도 마찬가지입니다.
구현이 해외 그룹(offshore groups)에 맡겨지는 경우에는, 결과물인 전략과 프로그램의 향후 유지보수 가능성을 보장하기 위해 더욱 엄격한 문서화 명세(documentation specifications)를 사용하는 것이 중요합니다. 또한 명세서의 준수를 보장하기 위해 공식적인 동료 검토 절차를 따르는 것이 더욱 중요합니다.
30.6 테스트(Testing)
자동화 시스템을 평가하는 기준은 두 가지입니다:
- 사람이 거의 개입하지 않고 제조 제품을 생산할 수 있는가?
- 자동화 시스템 자체가 공정의 병목이 되지 않을 만큼 충분히 빠르게 작동하는가?
테스트의 기준은 30.2.1절에서 설명한 제조 명세(manufacturing specification)입니다. 대규모 맞춤형 시스템은 종종 공정 시뮬레이션 환경에서 테스트되지만, 대부분의 제조 자동화 시스템은 온라인으로 테스트됩니다. 유체 공정 산업에서는 안전상의 이유로 많은 자동화 기능을 실제 공정 유체 대신 물을 채운 장비에서 테스트합니다.
프로그래머는 일반적으로 소프트웨어 승인 절차의 일환으로 커스텀 소프트웨어를 테스트합니다. 각 소프트웨어 모듈 또는 객체는 자동화 시스템 내의 다른 모듈이나 객체와 통합되기 전에 개별적으로 테스트되어야 합니다. 각 소프트웨어 모듈 또는 객체의 테스트 기준은 소프트웨어 설계 명세서(SDS, software design specification)입니다. 모든 소프트웨어 모듈과 객체를 통합한 후에는 SDS에 포함된 테스트 명세(test specifications)를 기반으로 전체 소프트웨어 프로젝트를 테스트해야 합니다.