PLC 시뮬레이션의 과제에서 배우기: 실용적인 가이드

2002년 Roland Schulz 씨의 논문에서 나온 이 묵직한 문장은 전반적으로 핵심을 잘 짚어줍니다.

간단히 말해: "시도하고 테스트하는 것이 오류를 찾는 데 도움이 된다."

여기서는 전체 생산 플랜트 시뮬레이션이 아닌, 자동화 프로그램이나 사용자 프로젝트 같은 개별 유닛(컴포넌트) 수준으로 원칙을 세분화해 보겠습니다.

과거 Phoenix Contact의 신입 직원 시절, 저도 프로그래밍을 배워야 했고 컨트롤러 시뮬레이션이 있었다면 블록이나 프로그램의 작동과 기능을 '시행착오'로 더 잘 이해할 수 있었을 것입니다. 안타깝게도 당시에는 그런 것이 없었고, 이후 나온 PLC 시뮬레이션도 매우 제한적이었습니다. IEC61131-3 코드는 잘 시뮬레이션할 수 있었지만, 특수 장치 지원이나 Intel, ARM, Motorola 기반 시스템 간의 코드 동작 차이는 부족했습니다.

이런 생각과 '클래식' PLC 시뮬레이션으로 겪었던 어려움을 떠올리며, 큰 노력 없이 실질적인 가치를 제공하는 것을 찾고자 했습니다. 개발 노력과 추후 사용 시 발생할 수 있는 노력 모두를 최소화하면서 말이죠.

사용자로서 저는 프로젝트를 PLC나 시뮬레이터로 마우스 클릭 한 번으로 보낼 수 있기를 원합니다. 프로세서 아키텍처에 신경 쓰고 싶지 않고, 시뮬레이터에서 지원하지 않는 기능 때문에 코드에서 기능을 숨기거나 제거해야 하는 상황은 더더욱 원치 않습니다.

실제 제어 하드웨어에서도 사용되는 실제 펌웨어를 시뮬레이션에 사용하면 어떨까요? 그게 바로 우리가 한 일입니다.

요즘은 다양한 운영체제를 Windows에서 실행할 수 있을 뿐만 아니라, 다양한 프로세서 아키텍처와 그 특성을 에뮬레이션하는 완전한 시스템 에뮬레이션이 있습니다.

우리 컨트롤러가 Linux 기반이라는 건 비밀이 아닙니다. 하지만 코드 개발에 있어 다양한 프로세서 아키텍처가 사용된다는 점이 중요합니다.

엔지니어링 툴인 PLCnext Engineer에서 고객은 컨트롤러의 IP 주소나 시뮬레이터 중 하나를 마우스 클릭 한 번으로 선택할 수 있어야 하며, 추가 코드 수정이나 바이너리 코드 호환성 걱정 없이 사용할 수 있어야 합니다.

이러한 생각의 결과는?

우리는 QEMU라는 시스템 에뮬레이션을 발견했고, 이를 우리 컨트롤러 시뮬레이션에 사용합니다. QEMU는 '오픈 소스 머신 에뮬레이션'으로 우리가 찾던 것을 정확히 제공합니다.

PLCnext Technology의 완전한 Linux 시스템(일부 PLCnext 컨트롤러의 ARM 프로세서 아키텍처 포함)을 에뮬레이션하는 QEMU에서 펌웨어를 '그저' 실행하면 됩니다. 그렇게 PLCnext 시뮬레이션이 탄생했습니다. 인정하건대, 몇 가지 작은 제한을 두었습니다. PROFINET 통신이나 다른 통신 프로토콜은 비활성화되어 있습니다. 하지만 OPC UA 서버는 영향을 받지 않습니다.

그러나 PLCnext Technology의 모든 특수 기능은 보존되었습니다. 따라서 C/C++, C#, Matlab Simulink 프로그램과 컴포넌트도 시뮬레이션으로 보낼 수 있습니다. Store에서 특정 애플리케이션용으로 찾을 수 있는 앱들도 실행할 수 있습니다.

몇 가지 추가 제한은 자명합니다. 이런 시뮬레이션 시스템에서 결정론을 기대할 수는 없습니다. 그리고 제 Windows 시스템의 부하에 따라 PLCnext 시뮬레이션에서 워치독이 발생할 수 있습니다. 하지만 그런 경우 Windows에서 시뮬레이션 프로세스에 더 높은 우선순위를 주면 워치독 오류가 빠르게 해결됩니다.

이제 마침내 저에게도 시뮬레이션이, 혹은 정의에 따라 에뮬레이션이 생겼습니다. 하지만 저는 그것 없이 프로그래밍을 배워야 했고, 지금은 예전만큼 프로그래밍을 하지 않습니다.