PLC 시뮬레이션의 고통스러운 기억

Roland Schulz가 2002년에 작성한 논문의 이 방대한 진술은 전체 내용을 잘 요약하고 있습니다.

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

이제 여기에서 전체 생산 공장의 시뮬레이션에 대해 글을 쓰는 것이 아니라 자동화 프로그램이나 사용자 프로젝트와 같은 개별 단위(구성 요소)로 원칙을 세분화합니다.

과거에는 피닉스컨택트의 젊은 직원이었을 때 프로그래밍도 배워야 했고 컨트롤러 시뮬레이션에 대해 만족했을 것입니다. "시도 및 오류"를 통해 블록 또는 프로그램의 작동 및 기능에 대해 자세히 알아보십시오. 불행히도 그 당시에는 존재하지 않았으며 이후의 PLC 시뮬레이션은 매우 제한적이었습니다. IEC61131-3 코드는 잘 시뮬레이션할 수 있지만 특수 장치에 대한 지원이 부족하거나 단순히 Intel과 ARM 또는 Motorola 기반 시스템 간의 코드 동작이 다릅니다.

이러한 생각과 PLC의 "고전적인" 시뮬레이션으로 겪었던 고통의 기억을 염두에 두고 우리는 큰 노력을 들이지 않고도 부가가치가 있는 무언가를 찾기 시작했습니다. 한편으로는 시뮬레이션 개발에 대한 노력과 나중에 사용할 수 있는 노력입니다.

사용자로서 기껏해야 마우스 클릭만으로 내 프로젝트를 PLC나 시뮬레이션으로 보낼 수 있기를 원합니다. 프로세서 아키텍처에 관심을 기울이고 싶지 않으며, 시뮬레이션에서 지원하지 않는 코드의 기능을 숨기거나 제거하도록 강요받고 싶지 않습니다.

실제 제어 하드웨어에서도 사용되는 시뮬레이션에서 실제 펌웨어를 사용하는 것보다 더 분명한 것은 무엇입니까? 그리고 바로 그 일이 일어났습니다.

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

컨트롤러가 Linux를 기반으로 한다는 것은 비밀이 아닙니다. 그러나 여기에서도 다른 프로세서 아키텍처가 사용되는 코드 개발이 중요합니다.

엔지니어링, 우리의 경우 PLCnext Engineer의 경우 고객은 추가 코드 적응이나 바이너리 코드 호환성에 대해 걱정할 필요 없이 한 번의 마우스 클릭으로 컨트롤러의 IP 주소 또는 시뮬레이션 중에서 선택할 수 있어야 합니다.

그 생각에서 무엇이 나왔나요?

시스템 에뮬레이션 QEMU를 찾았고 이를 사용하여 컨트롤러를 시뮬레이션했습니다. QEMU는 "오픈 소스 머신 에뮬레이션"입니다. 우리가 찾던 바로 그 제품을 제공합니다.

"그냥" 펌웨어를 실행하면 QEMU가 일부 PLCnext 컨트롤러의 ARM 프로세서 아키텍처를 포함하여 PLCnext Technology의 전체 Linux 시스템을 에뮬레이트합니다. 그리고 PLCnext 시뮬레이션이 탄생했습니다. 물론 몇 가지 사소한 제한 사항이 포함되어 있었습니다. PROFINET 통신 또는 기타 통신 프로토콜이 비활성화되었습니다. 그러나 예를 들어 OPC UA 서버는 영향을 받지 않습니다.

그러나 PLCnext Technology의 모든 특수 기능은 보존될 수 있습니다. 따라서 C/C++, C# 또는 Matlab Simulink 프로그램 및 구성 요소를 시뮬레이션에 보낼 수도 있습니다. 또한 Store에서 특정 애플리케이션에 대해 찾을 수 있는 APP를 실행에 가져올 수 있습니다.

몇 가지 추가 제한 사항은 분명합니다. 이러한 시뮬레이션된 시스템에서 결정론을 기대해서는 안 됩니다. 그리고 내 Windows 시스템의 로드에 따라 PLCnext 시뮬레이션에 하나 또는 다른 워치독이 있을 수 있습니다. 그러나 그러한 경우에는 항상 Windows 시스템에서 시뮬레이션 프로세스에 더 높은 우선순위를 부여할 수 있으며 그러면 워치독 오류가 신속하게 해결됩니다.

그리고 이제 마침내 시뮬레이션을 갖게 되었고, 정의에 따라 컨트롤러의 에뮬레이션이 될 수도 있습니다. 하지만 불행히도 컨트롤러 없이 프로그래밍을 배워야 했고 이제는 더 이상 프로그래밍을 하지 않습니다.