Design of an integrated control system for temperature focusing in microwave cancer hyperthermia
where tumor tissues are selectively heated to approximately 42–44 °C using non-ionizing microwave radiation.
서론
고온치료는 기존 암 치료법의 효과를 향상시키는 것으로 입증되어 21세기 들어 종양학 분야에서 꾸준히 관심을 받아왔습니다. 이 기술은 비이온화 전자기파, 일반적으로 마이크로파를 이용하여 종양 조직의 온도를 선택적으로 약 42~44°C까지 상승시킵니다.
방사선 치료 및/또는 화학 요법과 병용할 경우, 고온치료는 약물 또는 이온화 방사선의 필요량을 줄이면서 임상 결과를 개선할 수 있습니다.
이는 제어된 가열이 세포의 방사선 민감도를 증가시키고 혈류량 증가로 약물 흡수를 개선하기 때문이며,
이 모든 과정은 추가적인 독성 없이 이루어집니다. 결과적으로, 환자들은 더 나은 치료 효과와 더 적은 부작용, 그리고 전반적인 삶의 질 향상을 경험하게 됩니다.
고온치료의 치료 성공은 적절한 열량을 정확하게 전달하는 데 달려 있으므로, 마이크로파 에너지를 종양 부위에 정확하게 제어하고 집중시키는 것이 필수적입니다.
본 논문은 두경부 고온 치료 장치를 재현하기 위한 실험 장치를 고려합니다.
이 장치는 반고체 한천 기반 혼합물로 만들어진 목 모형을 둘러싼 8개의 패치 안테나의 원형 배열로 구성되며, 배열과 모형 사이에는 흐르는 물이 존재합니다(물 볼루스를 모사).
본 논문의 주요 목표는 위에서 설명한 실험 장치를 구동할 수 있는 통합 제어 시스템을 구현하는 모듈형 컴퓨터를 개발하는 것입니다.
기존의 전자 장치를 기반으로 개발된 시스템의 일반적인 작동 원리에 대한 영감을 얻었으며, 이를 바탕으로 구성 요소(집적 회로)를 선정하고, 회로도를 설계한 후 최종적으로 인쇄 회로 기판(PCB)으로 제작했습니다.
1) Introduction
학술 논문은 보통 문제 정의, 제안 기법, 성능 평가에 초점을 맞춥니다. 반면 maker.wiznet.io의 독자는 그 기술이 실제 하드웨어에서 어떻게 구현되고, 어떤 인터페이스를 통해 연결되며, 어떤 코드 구조로 동작하는지에 더 큰 관심을 가집니다. 그래서 이 글은 논문의 내용을 단순 요약하는 대신, **“무엇을 해결하는가 → 어떻게 구현하는가 → 어떻게 검증하는가 → 어디에 적용할 수 있는가”**라는 메이커 친화적인 흐름으로 다시 정리했습니다. 이런 구성은 배선, 환경 설정, 코드 예시, 테스트, 트러블슈팅까지 포함하는 maker.wiznet.io의 실전형 글 구조와도 잘 맞습니다.
이번 원고는 원문이 논문이라는 점을 고려해, 재현 가능한 프로토타입 관점에서 내용을 다시 설명합니다. 즉, 논문이 제안한 알고리즘·통신 방식·시스템 구조를 실제 임베디드 시스템이나 IoT 노드로 옮긴다면 어떤 부품이 필요하고, 어떤 버스로 연결하고, 어떤 테스트 절차로 검증할 수 있는지를 중심으로 접근합니다.
2) Required Components
현재 대화에는 논문의 구체적인 보드명, 센서명, SoC, 통신 토폴로지가 보이지 않으므로 아래는 reference implementation 기준입니다. 네트워크 연결이 필요한 논문이라면 W5500은 하드웨어 TCP/IP, 10/100 MAC, PHY를 내장한 SPI 기반 Ethernet 컨트롤러이고, W6100은 IPv4/IPv6 듀얼 스택을 지원하며, W55RP20은 W5500과 RP2040을 하나의 SiP로 통합해 부품 수를 줄이는 데 유리합니다.
| Category | Item | Notes |
|---|---|---|
| Main Controller | None | 논문에 명시된 MCU/MPU가 보이지 않음 |
| Network Interface | W5500 / W6100 / W55RP20 | reference implementation 후보 |
| Sensor / Input Device | None | 논문 핵심 입력 장치 |
| Actuator / Output Device | None | 제어·표시·응답용 |
| Power | 3.3V / 5V regulated supply | 보드에 따라 다름 |
| Debug Interface | UART | 로그 확인용 |
| Development PC | PC / Laptop | 코드 빌드 및 업로드 |
| Network Side | Router / Switch / Server | 테스트 환경 구성용 |
3) Hardware Setup
논문 기반 프로젝트를 메이커 환경으로 옮길 때 가장 중요한 것은 기능 블록을 분리해서 이해하는 것입니다. 보통 구조는 다음과 같이 정리할 수 있습니다.
- Input Layer: 센서, 외부 데이터, 사용자 입력
- Processing Layer: 논문의 핵심 알고리즘, 필터링, 추론, 제어 로직
- Communication Layer: 유선/무선 네트워크 전송
- Output Layer: 모니터링, 저장, 제어 신호, 서버 업로드
이 구조로 보면 논문에서 말하는 “제안 기법”은 대부분 Processing Layer에 해당합니다. 메이커 프로젝트에서는 여기에 하드웨어 입출력과 통신 계층을 더해 실제 동작 가능한 시스템으로 만드는 것이 핵심입니다.
reference implementation 기준으로는, 센서 또는 데이터 입력 장치를 MCU에 연결하고, MCU가 논문의 핵심 로직을 실행한 뒤, 결과를 Ethernet을 통해 서버나 PC로 전송하는 형태가 가장 이해하기 쉽고 확장성도 좋습니다. 이 접근은 연구 단계의 아이디어를 현장형 프로토타입으로 바꾸는 데 적합합니다.
4) Interface Explanation
SPI
SPI는 메이커 환경에서 가장 다루기 쉬운 고속 직렬 인터페이스 중 하나입니다. W5500은 외부 MCU와 SPI로 연결되며 최대 80MHz SPI를 지원하고, W6100 역시 SPI 기반으로 활용할 수 있는 하드웨어 TCP/IP Ethernet 컨트롤러입니다. 또한 두 칩 모두 10/100 Ethernet MAC과 PHY를 내장하고 있어 별도 PHY 설계 부담을 줄일 수 있습니다.
UART
UART는 논문의 실험 환경을 메이커 프로젝트로 옮길 때 가장 먼저 확보해야 하는 디버깅 채널입니다. 센서 초기화 상태, 추론 결과, 통신 실패 원인 등을 직렬 로그로 확인할 수 있기 때문에 재현성 확보에 매우 중요합니다.
RMII
논문이 자체 Ethernet MAC을 가진 MCU 또는 MPU를 전제로 한다면 RMII가 등장할 수 있습니다. 다만 W5500이나 W6100처럼 MAC/PHY를 내장한 Ethernet 컨트롤러를 쓰는 reference implementation에서는 보통 RMII가 필요하지 않습니다. 즉, 메이커 입장에서는 SPI 방식이 더 단순하고 빠르게 시작할 수 있는 선택지입니다.
5) Wiring Table
아래는 generic SPI Ethernet wiring reference입니다. 실제 핀 번호는 사용 보드에 맞게 바꾸면 됩니다.
| MCU Side | Ethernet Module Side | Description |
|---|---|---|
| MOSI | MOSI | SPI data out |
| MISO | MISO | SPI data in |
| SCLK | SCLK | SPI clock |
| CS | SCS / CS | Chip select |
| GPIO_RESET | RESET | Module reset |
| GPIO_INT | INT | Interrupt input |
| 3.3V | VCC | Power |
| GND | GND | Ground |
| UART TX | Debug RX | Optional debug |
| UART RX | Debug TX | Optional debug |
논문이 센서 기반이라면 여기에 I2C 또는 추가 SPI/UART 장치를 별도로 연결하면 됩니다. 핵심은 논문의 알고리즘 경로와 네트워크 전송 경로를 분리해서 배선하는 것입니다.
6) Software Environment Setup
논문을 메이커 프로젝트로 옮길 때 소프트웨어 환경은 다음 순서로 잡는 것이 안정적입니다.
- 보드 및 툴체인 선정
Arduino IDE, PlatformIO, STM32CubeIDE, ESP-IDF 등 보드에 맞는 개발 환경을 선택합니다. - 논문 핵심 로직 분리
논문의 수식, 모델, 제어 알고리즘, 데이터 처리 부분을 별도 함수 또는 모듈로 분리합니다. - 입출력 계층 구성
센서 읽기, 액추에이터 출력, UART 로그, Ethernet 송수신을 각각 함수 단위로 나눕니다. - 네트워크 초기화
DHCP 또는 Static IP 설정, 서버 주소, 포트, 전송 주기 등을 정의합니다. - 데이터 포맷 설계
CSV, JSON, 바이너리 패킷 중 하나를 선택해 논문 실험 결과를 전송 가능한 형식으로 정리합니다.
이렇게 하면 논문의 이론적 기여와 임베디드 구현 코드가 뒤섞이지 않아 디버깅이 쉬워집니다.
7) Full Code Examples
아래 예시는 논문 핵심 알고리즘을 Ethernet 기반 프로토타입으로 연결하는 reference skeleton입니다. 실제 프로젝트에서는 readPaperInput()과 runPaperAlgorithm() 부분을 논문 내용에 맞게 바꾸면 됩니다.
#include <Ethernet.h>
byte mac[] = { 0x02, 0xAB, 0xCD, 0xEF, 0x00, 0x01 };
IPAddress server(192, 168, 0, 10);
EthernetClient client;
float readPaperInput() {
// Replace this with sensor acquisition or paper-specific preprocessing
return 0.0f;
}
float runPaperAlgorithm(float input) {
// Replace this with the paper's core logic:
// filtering, classification, prediction, control, etc.
return input;
}
void setup() {
Serial.begin(115200);
// Example CS pin for SPI Ethernet module
Ethernet.init(10);
// Start Ethernet with DHCP
if (Ethernet.begin(mac) == 0) {
Serial.println("DHCP failed. Check cable or network.");
} else {
Serial.print("IP Address: ");
Serial.println(Ethernet.localIP());
}
}
void loop() {
float inputValue = readPaperInput();
float resultValue = runPaperAlgorithm(inputValue);
if (client.connect(server, 5000)) {
client.print("{\"input\":");
client.print(inputValue, 4);
client.print(",\"result\":");
client.print(resultValue, 4);
client.println("}");
client.stop();
Serial.println("Data sent");
} else {
Serial.println("Network send failed");
}
delay(1000);
}
이 코드의 장점은 구조가 단순하다는 점입니다.
- 센서 입력
- 논문 로직 실행
- 네트워크 전송
이 세 단계를 분리하면, 논문의 실험 알고리즘을 실제 시스템에 이식할 때 어디서 문제가 발생하는지 빠르게 찾을 수 있습니다.
8) Testing Steps
- Local Logic Test
네트워크를 붙이기 전에 논문의 핵심 연산이 단독으로 정상 동작하는지 확인합니다. - Serial Debug Test
입력값, 중간 계산값, 최종 결과를 UART 로그로 출력해 기대값과 비교합니다. - Network Bring-up Test
IP 할당, 링크 업, 서버 접속 여부를 확인합니다. - End-to-End Transmission Test
논문 로직 결과가 실제로 서버 또는 PC에 도착하는지 확인합니다. - Repeatability Test
여러 번 반복 실행해 논문에서 주장하는 결과 경향과 유사한지 검증합니다. - Stress / Long-run Test
장시간 구동 시 메모리 누수, 소켓 오류, 데이터 누락이 없는지 확인합니다.
9) Troubleshooting
Ethernet link가 올라오지 않을 때
케이블, RJ45 연결, 전원 안정성, SPI 배선을 먼저 확인합니다. CS 핀 설정 오류도 매우 흔한 원인입니다.
DHCP 실패가 반복될 때
라우터 연결 상태를 점검하고, 우선 Static IP로 전환해 Ethernet 계층부터 확인합니다.
논문 결과와 수치가 맞지 않을 때
센서 샘플링 주기, 정규화 방식, 고정소수점/부동소수점 처리 차이, 초기 조건을 재검토해야 합니다. 논문은 작은 실험 조건 차이로도 결과가 달라질 수 있습니다.
통신은 되지만 데이터가 이상할 때
전송 포맷(JSON/CSV/바이너리), 엔디언, 문자열 길이, 버퍼 크기를 확인합니다.
장시간 동작 중 멈출 때
소켓 재사용 방식, 메모리 파편화, 무한 대기 루프, 재시도 로직을 점검해야 합니다.
10) Use Cases & Market Potential
논문이 메이커 사이트에서 의미를 가지는 이유는, 연구가 실제 제품과 서비스로 넘어가는 출발점을 보여주기 때문입니다. 논문의 아이디어를 프로토타입으로 옮기면 다음과 같은 응용으로 연결될 수 있습니다.
- 산업 설비 모니터링
- 환경 데이터 수집 및 원격 로깅
- 스마트 농업 센싱 노드
- 예지보전용 네트워크 엣지 디바이스
- 실험실 장비의 원격 계측
- 스마트 빌딩 제어 시스템
- 교육용 연구-프로토타입 변환 사례
시장 관점에서도, 논문 기반 프로젝트는 단순 데모를 넘어서 검증된 아이디어를 빠르게 현장형 PoC로 바꾸는 방법을 제시합니다. 특히 네트워크 연결이 필요한 분야에서는 데이터 수집, 원격 제어, 유지보수 자동화까지 연결되므로 실용성이 높습니다.
11) Module/Chip Technical Overview
W5500
W5500은 하드웨어 TCP/IP 스택과 10/100 Ethernet MAC/PHY를 통합한 Ethernet 컨트롤러이며, 외부 MCU와 SPI로 연결됩니다. 공식 문서 기준으로 SPI는 최대 80MHz를 지원하고, 임베디드 시스템에 인터넷 연결 기능을 비교적 단순하게 추가할 수 있도록 설계되어 있습니다. 따라서 IPv4 기반의 저복잡도 유선 프로토타입에 적합합니다.
W6100
W6100은 WIZnet의 하드웨어 TCP/IP 기술을 기반으로 하면서 IPv4와 IPv6를 모두 지원하는 듀얼 스택 Ethernet 컨트롤러입니다. 공식 문서에는 8개의 하드웨어 소켓과 32KB 내부 메모리가 명시되어 있어, 차세대 네트워크 호환성이나 IPv6 실험이 필요한 논문 재현에 더 잘 맞습니다.
W55RP20
W55RP20은 W5500 Ethernet 컨트롤러와 Raspberry Pi RP2040 MCU를 하나의 SiP로 통합한 칩입니다. 공식 문서상 네트워킹과 프로세싱을 함께 제공하므로, 보드 면적과 BOM을 줄이면서도 네트워크 기능을 빠르게 붙이고 싶은 프로젝트에 유리합니다. 따라서 컴팩트한 연구용 노드나 소형 PoC 보드에 적합하다고 볼 수 있습니다. 이는 공개된 통합 구조를 바탕으로 한 엔지니어링적 해석입니다.
정리하면,
- W5500: 단순하고 안정적인 IPv4 유선 연결
- W6100: IPv6까지 고려한 확장형 네트워크
- W55RP20: MCU + Ethernet 통합형 소형 설계
라는 방향으로 선택하면 됩니다. 이 구분은 각 칩의 공식 기능 설명을 바탕으로 한 실무적 판단입니다.