1. Modbus-RTU 와 SCADA 시스템
RS485 기반의 Modbus RTU 구조는 이전의 문서들을 참조 하도록 하자.
RS485 Modbus 와 SCADA 시스템1
RS485 Modbus 와 SCADA 시스템2
Modbus-RTU 기반으로 각 Device들을 구현하면, 최종적으로 이 기반으로 OTA도 별도로 구현을 하고 싶어할 것이다.
하지만, 안타깝게도, 이것으로, OTA를 해주는 기능은 없으며, 별도로 본인 Protocol 정의해서 구현을 해야한다.
1.1 Modbus-RTU Memory Map
우선 Modbus-RTU는 Device에게 Data Read only 와 Read/Write만 제공하는 단순한 Protocol이다.
이를 좀 더 세부적으로 제어하기 위해서는 별도 Protocol 정의하고 부족한 부분을 채워 각 기능을 보완을 해야한다.
예를들면, OTA 구현이라든지, Device 세부제어라든지, 이런 요소들을 위해서 각 Memory Map 정의하도록 하자
- Input Register (Read only 2byte)
- Modbus RTU Status
- System Status
- Each Event
- System Information
- Holding Register (Read/Write 2byte)
- Modbus RTU Command
- Modbus RTU Status
- Modbus RTU Error
- Modbus RTU Argument
- Modbus RTU Buffer
- 이외 System Setup
내가 생각한 것은 간단하게 Command 기반으로 각 상태를 만들어 Device를 구동시키는 방법이다.
상위와 같이 각 Modbus RTU Command를 각 만들어 Command Driven 방식으로 간단히 device driver를 보완하여 만들어 보자.
유사하다면, MMC가 될 수도 있겟으며, 상위처럼 구현할 경우, 반드시 Master에서 구현하고 테스트를 해봐야 한다.
- eMMC/SDCard Interface
MMC Spec 세부적으로 보면, 각 CMD 의 상태도가 있으며, 이부분과 비슷하다.
1.2 Modbus-RTU 기반 OTA
Modbus 가 기본적으로 Request/Response 기반이므로, SCADA(Master), 특정 Register를 Command 기반으로 변경하여 진행하도록 한다.
이에 대한 반응 항상 특정 Resiter를 통해, Deivce Status 체크하는 구조이다.
상위에서 언급한 MMC가 이런 방식으로 동작하며, 다양한 Device Driver들이 이와 유사한다.
그리고, 각 Command마다 Flow 및 Status가 본인 알아서 정의하도록 하자.
- OTA 구현시 문제사항
OTA를 진행할 경우, Modbus-RTU 에서는 많은 Data를 전송하기 때문에, 여기에도 좀 문제가 발생하는데,
주로 Cache(CPU Cache가 아니며, Buffer)로 인하여, 중복되는 문제 부분일 것 같다.
이 부분은, OTA 진행 할 경우,
RS232의 Flow Control 이 존재하지만, RS485에서 크게 의미가 없어서, 별도로, S/W Flow Control Header 정의해서, 이 부분을 보완하였다.
테스트를 해봤지만, RS232 Flow Control이 RS485로 되면서 별의미가 없고, Modbus-RTU(RS485)는 내부적으로 Flow Control이 없는걸로 생각되어짐
이 부분은 간단히 정의해서 이 부분을 보완하여 넣도록하자.
예를들면, 각 Offset 과 Size 정의하고, 이를 Master 와 Slave가 각각 확인하는 구조이며, 이외 Buffer 성능 및 에러문제등을 개선하여 만들어 보도록하자.
이외 다양한 문제가 발생할 수 있으며, 각 상황에 맞추어 본인이 세부적으로 분석해서 대응하자.
- 나의 경우는 HW적으로 다음과 같은 문제가 발생
- RS485 Tranceiver 의 오동작 ( Reset 후 발생 문제가 발생)
- Master에서 Response를 제대로 못가져오는 문제
- 이 문제가 발생하여 상위 Flow Control 기능추가
- ESP32의 FreeRTOS 문제 및 성능문제
- 이 문제는 S/W 문제가 다양하며, Serial 부분과 많이 연관되어짐
- Serial Buffer 이외 FreeRTOS Buffer도 별도로 존재
일단 나의 경우는 각 OTA Command 와 Status를 별도로 정의하여 구현했으며, 테스트 결과 별 이상이 없다.
더불어, 좀 더 세부적으로 성능 및 OTA 테스트 분석하기 위해서 Python 기반으로 이를 OTA 테스트 하는 Program을 작성하였다.
또한 Modbus RTU 기능을 간단히 Profiling (RS485 버스 점유율 및 속도)해주는 Program도 별도 추가구현 하였다.
만약, 이를 상용으로 동작되는 프로그램있다면,이를 적극 이용하거나, 그 Tool에 맞게 제작 하도록하자.
구지, 나처럼 다 일일이 만들지 말도록 하자.
주로 Profiling 하는 부분은 ESP32의 RS485/Modbus-RTU 성능이므로, 이 Bus 점유율(Share-rate)를 각 속도별로 비교해보면 되겠다.
그리고, 각 에러율도 좀 비교해보면 더욱 좋겠다. (이 부분은 만들었지만, 비교하지 않았다)
참고로, ESP32의 경우, 속도가 높아질수록 성능 많이 부족해지는데, 다른 곳에 많은 리소스를 사용해서 그런건지,(아마 이쪽이 가능성이 높다)
아님 ESP32 문제인지는 나도 아직 세부적으로 분석하지 않았다.
2. SCADA 에 Modbus RTU 적용문제
나 역시, 정확한 SCADA를 실제로 접해 본적이 없기에, 이에 적용하는 방법은 본인 정한 Protocol Flow와 Memory Map 을 알려주는 방법 밖에는 없는 거 같다.
나의 경우, Python 기반으로 나만의 Master기반으로 직접 테스트하며 구현했기 때문에, 이 부분은 나중에 한 번 다시 한번 생각해봐야겠다.
2.1 Python 기반 Unit 테스트
Modbus 역시, Python 과 NodeJS도 지원해주기 때문에, 본인 작성하기 쉬운 걸로 선택해서 각 테스트 프로그램들을 작성하도록 하자.
상위에 이미 설명을 했으며, 각 OTA 성능 및 Profile을 위해서 가 부분을 비교 분석하도록 하였다.
내가 TEST Program을 작성하면서, 어려움이라고 하면, 각 Python Library 찾는 법?
나머지는, 구글링하면, Python은 대충 작성이 가능한 것 같다.
(다만 본인이 동작하는 원리와 프로토콜 설계를 이해를 해야 하겠지만)
참고로, 최근에 상위처럼 5대가 아니라, RS485로 현재 8대까지 40 meter로 테스트 했을 때도 OTA와 다른 Control 크게 문제가 되지 않았다.
Python (pymodbus)
2.2 VS Code 의 Unit TEST (Automated)
외부 DevOps 처럼, 완전히 Cloud 내부에서 하는 것은 아니지만, 본인 개발환경에서 쉽게 가능하다.
나의 경우, Github에서는 CircleCI를 이용하지만, VS Code Manaul보면, 외부에서도 아래와 같이 쉽게 본인 마음대로 Power Shell Script 기반으로 구성가능하다.
VS Code를 이용하여 자동화
완벽히 Jenkins는 아니여도, 얼추 Jenkins 느낌처럼 구성가능하다.
댓글 없음 :
댓글 쓰기