📘 BÀI 9 – “BỘ NÃO” CỦA LINAC
Control System, Interlock, Sensor, Watchdog và Beam-Permission
Ở Bài 8, chúng ta đã đi xuyên qua đường đi của chùm tia:
Electron Gun → Accelerator → Target → Monitor Chamber → Jaw → MLC → Patient
Bây giờ chúng ta đổi góc nhìn.
Không nhìn LINAC như một máy vật lý nữa, mà nhìn nó như một hệ thống điều khiển điện tử – cơ điện – phần mềm – an toàn tích hợp.
⚠️ Các sơ đồ dưới đây là mô hình học tập khái niệm, không phải sơ đồ service của một LINAC thương mại cụ thể. Các kiến trúc thực tế khác nhau tùy hãng/model.
1. LINAC thực chất là một hệ thống điều khiển khổng lồ
Có thể hình dung:
┌───────────────┐
│ OPERATOR │
│ CONSOLE │
└───────┬───────┘
│
▼
┌───────────────┐
│ CONTROL │
│ SYSTEM │
└───────┬───────┘
│
┌───────────────────┼──────────────────┐
▼ ▼ ▼
GANTRY MLC RF
│ │ │
▼ ▼ ▼
MOTORS MOTORS POWER SYSTEM
│ │ │
▼ ▼ ▼
SENSORS ENCODERS MONITORS
│ │ │
└───────────────────┼──────────────────┘
▼
SAFETY / INTERLOCK
│
▼
BEAM PERMISSION
Điều quan trọng là:
Control system ≠ Safety system.
Đây là hai khái niệm chúng ta sẽ liên tục phân biệt trong bài này.
2. Tại sao không dùng một Arduino để điều khiển toàn bộ LINAC?
Giả sử ta viết:
if (doorClosed &&
gantryOK &&
mlcOK &&
vacuumOK &&
rfOK) {
beamOn();
}
Về mặt lập trình, nhìn rất hợp lý.
Nhưng đối với một hệ thống y tế an toàn cao, không thể chỉ dựa vào một đoạn code như vậy.
Vấn đề là:
Software bug
↓
Wrong decision
↓
Beam ON
Hoặc:
CPU failure
↓
No control
↓
???
Safety-critical system phải được thiết kế để một lỗi đơn lẻ không dễ dàng dẫn đến trạng thái nguy hiểm.
3. Control System và Safety System
Hãy tách chúng ra.
Control system
Có nhiệm vụ:
- điều khiển chuyển động
- xử lý treatment plan
- điều khiển beam parameters
- giao tiếp với operator
- đọc trạng thái hệ thống
Safety system
Có nhiệm vụ lớn hơn:
Ngăn hệ thống đi vào trạng thái nguy hiểm hoặc ngừng beam khi điều kiện an toàn không còn được thỏa mãn.
Sơ đồ:
CONTROL SYSTEM
│
▼
Machine commands
│
▼
┌─────────────┐
│ SAFETY │
│ SYSTEM │
└──────┬──────┘
│
┌─────────┴─────────┐
▼ ▼
PERMIT INHIBIT
│ │
▼ ▼
Beam OK Beam OFF
4. Khái niệm Beam Permission
Một khái niệm rất quan trọng:
Beam Permission
Hiểu đơn giản:
Hệ thống chỉ cho phép beam hoạt động khi các điều kiện cần thiết đã được xác nhận.
Ví dụ mô hình:
Door CLOSED
│
├──►
Gantry OK
│
├──►
MLC OK
│
├──►
Beam parameters OK
│
├──►
Monitoring OK
│
▼
BEAM PERMISSION
│
▼
BEAM ENABLE
Nếu một điều kiện mất:
Door OPEN
│
▼
BEAM PERMISSION = FALSE
│
▼
BEAM INHIBIT
5. Beam Permission không phải một nút ON/OFF đơn giản
Đây là điểm quan trọng.
Không nên hình dung:
Button
↓
BEAM ON
Mà nên hình dung:
┌── Door
├── Gantry
├── MLC
├── Monitoring
├── Treatment parameters
├── Safety conditions
│
▼
PERMISSION LOGIC
│
┌──────┴──────┐
▼ ▼
PERMIT INHIBIT
6. Sensor
LINAC có rất nhiều loại cảm biến.
Ví dụ về mặt khái niệm:
Position sensor
Temperature sensor
Pressure sensor
Door switch
Current monitor
Voltage monitor
Encoder
Radiation monitor
Flow sensor
...
Chúng biến trạng thái vật lý thành tín hiệu mà hệ thống có thể giám sát.
7. Ví dụ Door Sensor
Cửa phòng có thể được giám sát bởi interlock.
Mô hình:
Door
│
▼
[Sensor]
│
▼
Safety input
│
▼
Interlock logic
Nếu:
Door = CLOSED
thì điều kiện có thể hợp lệ.
Nếu:
Door = OPEN
thì beam phải bị inhibit theo thiết kế an toàn.
8. Encoder
Đây là linh kiện bạn sẽ rất dễ liên tưởng tới các dự án STM32.
Encoder dùng để xác định vị trí/chuyển động.
Ví dụ:
Motor
│
▼
Encoder
│
▼
Position feedback
│
▼
Controller
Ví dụ gantry:
Command:
Gantry → 90°
│
▼
Motor
│
▼
Encoder
│
▼
Actual = 89.98°
Controller có thể so sánh:
Target position
vs
Actual position
9. Closed-loop control
Đây là một kiến thức điều khiển học rất quan trọng.
┌──────────────┐
│ Controller │
└──────┬───────┘
│
Command
▼
Motor
│
▼
Mechanism
│
▼
Encoder
│
└──────────────┐
│
▼
Feedback
Đây gọi là:
Closed-loop control
10. Ví dụ với gantry
Operator/TPS yêu cầu:
Gantry = 180°
Controller ra lệnh:
Motor → rotate
Encoder trả về:
20°
50°
100°
150°
175°
179°
180°
Khi đạt vị trí phù hợp:
Position OK
11. Nhưng “180°” không chỉ là một con số
Trong hệ thống thật, còn phải quan tâm:
- actual position
- commanded position
- tolerance
- direction
- speed
- acceleration
- encoder validity
- mechanical status
Do đó:
COMMAND = 180°
không có nghĩa:
ASSUME ACTUAL = 180°
Hệ thống phải đo.
12. MLC cũng tương tự
TPS có thể yêu cầu:
Leaf A → position X
Leaf B → position Y
Leaf C → position Z
Controller:
Command
↓
Motor
↓
MLC leaf
↓
Position feedback
↓
Controller
Nếu actual position không phù hợp:
MLC mismatch
↓
Fault / beam inhibit
Cách triển khai cụ thể phụ thuộc hệ thống.
13. Watchdog
Đây là khái niệm cực kỳ quen thuộc trong embedded systems.
Watchdog Timer
Nó giúp phát hiện controller/software không còn hoạt động đúng như kỳ vọng.
Ví dụ:
CPU
│
├── normal operation
│
├── heartbeat
│
├── heartbeat
│
└── heartbeat
Watchdog được reset định kỳ.
Nếu CPU bị treo:
CPU
│
X
│
No heartbeat
│
▼
WATCHDOG TIMEOUT
│
▼
SAFE RESPONSE
14. Tại sao watchdog quan trọng?
Giả sử CPU bị:
Infinite loop
hoặc:
Memory corruption
hoặc:
Software deadlock
Nếu không có cơ chế giám sát:
CPU frozen
↓
System state uncertain
Safety architecture cần đưa hệ thống về trạng thái an toàn phù hợp.
15. Nhưng watchdog cũng không đủ
Đây là điểm cực kỳ quan trọng.
Không thể nói:
“Có watchdog rồi nên an toàn.”
Không.
Watchdog chỉ giải quyết một nhóm lỗi nhất định.
Safety cần nhiều lớp:
Watchdog
+
Interlock
+
Monitoring
+
Redundancy
+
Hardware protection
+
Software checks
+
QA
+
Procedures
16. Redundancy
Một khái niệm rất quan trọng:
Redundancy – dự phòng
Ví dụ đơn giản:
Sensor A ─────┐
├── Safety logic
Sensor B ─────┘
Nếu hai tín hiệu không nhất quán:
A = CLOSED
B = OPEN
hệ thống không nên đơn giản giả định:
“Chắc chắn là CLOSED.”
Thay vào đó:
Mismatch
↓
Fault
↓
Beam inhibit
17. Fail-safe
Đây là một trong những từ quan trọng nhất của bài:
FAIL-SAFE
Hiểu đơn giản:
Khi xảy ra lỗi, hệ thống ưu tiên chuyển về trạng thái an toàn hơn thay vì tiếp tục hành động nguy hiểm.
Ví dụ khái niệm:
Normal
│
▼
BEAM ENABLED
Fault
│
▼
BEAM INHIBITED
18. Ví dụ cực đơn giản
Giả sử:
Door sensor = UNKNOWN
Hai cách thiết kế:
Thiết kế nguy hiểm
UNKNOWN → assume CLOSED
Tư duy fail-safe
UNKNOWN → NOT SAFE
→ BEAM INHIBIT
Đây là tư duy rất quan trọng trong safety engineering.
19. Fault ≠ Interlock ≠ Emergency
Ba khái niệm này dễ bị nhầm.
Interlock
Một điều kiện cần thiết không còn đúng.
Condition invalid
↓
Beam inhibit
Fault
Hệ thống phát hiện một trạng thái bất thường/lỗi.
Fault
↓
Safe response
Emergency
Tình huống cần hành động khẩn cấp theo thiết kế và quy trình.
Không phải mọi model LINAC đều dùng thuật ngữ và kiến trúc giống nhau.
20. Emergency Stop
Một hệ thống có thể có các nút/cơ cấu emergency stop tại những vị trí thích hợp.
Mô hình:
EMERGENCY STOP
│
▼
SAFETY SYSTEM
│
▼
SAFE STATE
Điểm quan trọng:
Không nên tự suy ra rằng Emergency Stop luôn có nghĩa “cắt toàn bộ điện của mọi subsystem”.
Chức năng thực tế phải xem tài liệu của model cụ thể.
21. Interlock chain
Một mô hình học tập:
Door OK
│
▼
Gantry OK
│
▼
MLC OK
│
▼
RF OK
│
▼
Monitor OK
│
▼
Treatment conditions OK
│
▼
BEAM PERMISSION
Chỉ cần một điều kiện quan trọng không đạt:
┌── Door OK
├── Gantry OK
├── MLC OK
├── RF OK
└── Monitor OK
│
▼
PERMISSION
│
X
One fault
│
▼
INHIBIT
22. Vì sao interlock phải đáng tin cậy?
Hãy tưởng tượng:
Door OPEN
nhưng software lại nhận:
Door CLOSED
Đây là một lỗi nghiêm trọng.
Vì vậy safety-critical input cần kiến trúc và kiểm tra phù hợp để giảm nguy cơ:
Real world ≠ system belief
23. Sensor diagnostics
Một hệ thống tốt không chỉ hỏi:
Sensor = 0 or 1?
Mà còn có thể cần biết:
Sensor valid?
Signal plausible?
Wiring OK?
Redundant channel agreement?
Communication healthy?
Ví dụ:
Position = 180°
Encoder = INVALID
thì:
180° alone
không đủ để kết luận hệ thống an toàn.
24. Communication fault
LINAC có rất nhiều subsystem.
Ví dụ:
Main Controller
│
├── Gantry controller
├── MLC controller
├── Imaging system
├── RF system
└── Treatment console
Nếu communication bị mất:
Controller
X
Subsystem
hệ thống phải xử lý tình huống đó theo kiến trúc an toàn.
25. Timeout
Một kỹ thuật rất phổ biến trong embedded systems:
Send command
↓
Wait response
↓
Timeout?
Nếu:
No response
thì:
FAULT
thay vì chờ vô hạn.
26. CRC / data integrity
Khi truyền dữ liệu giữa các controller, một hệ thống có thể sử dụng các cơ chế kiểm tra tính toàn vẹn dữ liệu.
Ví dụ khái niệm:
Command
+
CRC
↓
Communication
↓
Check
Nếu dữ liệu bị lỗi:
CRC mismatch
↓
Reject data
Đây là tư duy rất quen thuộc trong embedded communication.
27. Nhưng đừng nhầm “data integrity” với “safety”
CRC giúp phát hiện lỗi truyền dữ liệu.
Nó không đảm bảo:
dữ liệu đúng về mặt lâm sàng.
Ví dụ:
100 MU
có thể truyền hoàn toàn chính xác.
Nhưng nếu treatment plan ban đầu sai:
Wrong plan
↓
Perfectly transmitted
↓
Still wrong
Do đó safety cần nhiều lớp hơn.
28. State Machine của LINAC
Đây là phần tôi nghĩ bạn sẽ rất thích vì nó rất giống cách chúng ta lập trình STM32.
Một FSM đơn giản:
POWER_ON
│
▼
INIT
│
▼
IDLE
│
Conditions OK
│
▼
READY
│
Start treatment
│
▼
BEAM_ON
│
Delivery complete
│
▼
BEAM_OFF
│
▼
READY
29. Fault có thể xuất hiện ở bất kỳ đâu
POWER_ON ───────► INIT
│
▼
IDLE
│
▼
READY
│
▼
BEAM_ON
Nếu fault:
ANY STATE
│
▼
FAULT
│
▼
SAFE / BEAM INHIBIT
Đây chính là tư duy:
State + Transition + Guard + Fault
30. Guard condition
Ví dụ:
READY → BEAM_ON
không xảy ra chỉ vì operator nhấn Start.
Phải có các guard conditions phù hợp.
Khái niệm:
Start command
│
▼
[All required conditions true?]
│
┌──┴──┐
│ │
YES NO
│ │
▼ ▼
BEAM INHIBIT
31. Đây chính là tư duy embedded engineering
Bạn có thể viết một mô hình giả lập:
if (doorOK &&
gantryOK &&
mlcOK &&
monitorOK &&
emergencyOK) {
state = READY;
}
Nhưng trong hệ thống thực tế:
Safety architecture không thể được suy giản thành một đoạn Arduino code như vậy.
Đoạn trên chỉ thích hợp cho mô phỏng giáo dục.
32. Safety Layer và Control Layer
Hãy nhìn theo hai tầng:
OPERATOR
│
▼
┌────────────────┐
│ CONTROL LAYER │
└───────┬────────┘
│
commands
│
▼
┌────────────────┐
│ SAFETY LAYER │
└───────┬────────┘
│
permit/inhibit
│
▼
BEAM SYSTEM
Control nói:
“Tôi muốn làm X.”
Safety hỏi:
“Có được phép làm X không?”
33. Đây là nguyên tắc rất hay
Control requests. Safety permits.
Không nên tư duy:
Control ra lệnh → máy chắc chắn làm.
Mà:
Control Request
↓
Safety validation
↓
Permission
↓
Action
34. Ví dụ MLC
Control:
MLC → Position X
Feedback:
Actual = X + Δ
Safety/control có thể kiểm tra tolerance theo thiết kế.
Nếu ngoài điều kiện cho phép:
MLC position mismatch
↓
Treatment condition invalid
↓
Beam inhibit
35. Ví dụ gantry
Plan:
Gantry = 90°
Encoder:
Actual = 89°
Tùy tolerance và trạng thái delivery, hệ thống xác định có hợp lệ hay không.
Nếu không:
Position error
↓
Fault
↓
Beam inhibited
Điểm quan trọng là:
Không chỉ kiểm tra lệnh; phải kiểm tra trạng thái thực tế.
36. Monitor Chamber + Control
Quay lại Bài 8.
Beam đang phát:
Beam
↓
Monitor Chamber
↓
Signal
↓
Control / monitoring
Nếu hệ thống phát hiện output không phù hợp:
Abnormal monitoring
↓
Fault / inhibit
Kiến trúc thực tế phức tạp hơn nhiều và có các yêu cầu an toàn riêng.
37. Watchdog + Interlock
Hai cái này khác nhau.
Watchdog
Theo dõi:
Controller/software có còn hoạt động như kỳ vọng không?
Interlock
Theo dõi:
Điều kiện vật lý/hệ thống có cho phép beam hay không?
Ví dụ:
CPU healthy?
│
▼
Watchdog
Door closed?
│
▼
Interlock
38. Redundancy + diversity
Một khái niệm nâng cao hơn:
Diversity
Không chỉ có hai hệ thống giống nhau.
Đôi khi safety architecture có thể sử dụng các cơ chế khác nhau để giảm nguy cơ cùng mắc một lỗi chung.
Ví dụ khái niệm:
Software check
+
Independent hardware check
Nếu cả hai cùng dựa vào đúng một bug, redundancy đơn thuần có thể không đủ.
39. Common Cause Failure
Đây là khái niệm rất quan trọng trong safety engineering.
Ví dụ:
Sensor A ──┐
├── same faulty power supply
Sensor B ──┘
Hai sensor có vẻ “redundant”.
Nhưng nếu nguồn chung hỏng:
Power failure
↓
A fails
B fails
→ redundancy không còn độc lập hoàn toàn.
Đây là lý do thiết kế safety thực tế phức tạp.
40. Fail-safe vs Fault-tolerant
Hai khái niệm gần nhau nhưng không giống nhau.
Fail-safe
Khi lỗi xảy ra:
chuyển về trạng thái an toàn.
Fault-tolerant
Hệ thống:
vẫn có thể tiếp tục thực hiện chức năng sau một số lỗi.
Trong safety-critical system, hai tư duy này có thể cùng xuất hiện ở các tầng khác nhau.
41. Human-machine interface – HMI
Bây giờ quay lại màn hình điều khiển.
Operator có thể thấy:
┌──────────────────────────┐
│ LINAC STATUS │
├──────────────────────────┤
│ GANTRY 180.0° │
│ COLLIMATOR 0.0° │
│ MLC READY │
│ DOOR CLOSED │
│ BEAM OFF │
│ SYSTEM READY │
└──────────────────────────┘
Nhưng HMI không phải là safety system.
Nó chỉ hiển thị trạng thái và cung cấp giao diện điều khiển theo kiến trúc được thiết kế.
42. “READY” không có nghĩa “beam đang ON”
Rất quan trọng:
READY
thường có nghĩa gần với:
hệ thống đang ở trạng thái sẵn sàng cho một thao tác điều trị phù hợp.
Trong khi:
BEAM ON
là trạng thái beam đang được phát.
Do đó:
READY ≠ BEAM ON
43. “NOT READY”
Ví dụ:
┌────────────────────┐
│ NOT READY │
│ │
│ Door: CLOSED │
│ Gantry: OK │
│ MLC: NOT READY │
└────────────────────┘
Operator cần biết tại sao.
Có thể là một condition chưa đạt hoặc fault.
44. Fault display
Ví dụ học tập:
┌────────────────────┐
│ SYSTEM FAULT │
├────────────────────┤
│ MLC POSITION │
│ MISMATCH │
│ │
│ BEAM INHIBITED │
└────────────────────┘
Đây là cách HMI giúp operator hiểu trạng thái.
45. Audit trail
Một hệ thống y tế quan trọng thường cần khả năng trace dữ liệu phù hợp.
Khái niệm:
Operator action
↓
Timestamp
↓
Treatment event
↓
Machine state
↓
Record
Điều này giúp:
- truy vết
- kiểm tra
- QA
- điều tra sự cố
theo quy trình của cơ sở.
46. Tại sao software trong LINAC khó hơn Arduino?
Arduino:
Compile
↓
Upload
↓
Test
LINAC:
Requirement
↓
Architecture
↓
Implementation
↓
Verification
↓
Validation
↓
Risk analysis
↓
Configuration management
↓
Testing
↓
Release
↓
Maintenance
Đây là tư duy của medical device software engineering.
47. Safety Integrity
Một hệ thống safety-critical phải xem xét:
Hazard
↓
Risk
↓
Safety requirement
↓
Design
↓
Verification
↓
Validation
Ví dụ:
Hazard:
Beam delivered under wrong condition
↓
Safety requirement:
Beam must be inhibited when required condition is invalid.
↓
Design:
Interlock / monitoring / control architecture
↓
Verification:
Test the safety behavior.
48. Risk không chỉ đến từ phần mềm
Một LINAC có thể gặp:
Mechanical fault
Electrical fault
Sensor fault
Software fault
Communication fault
Human error
Calibration drift
Environmental condition
Maintenance error
Do đó safety phải bao phủ toàn hệ thống.
49. Defense in Depth một lần nữa
Bây giờ ta có thể nhìn nó sâu hơn:
SAFETY
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Hardware Software Human
│ │ │
▼ ▼ ▼
Interlock Validation Procedure
│ │ │
└──────────────┼──────────────┘
▼
Monitoring
│
▼
QA
Đây là tư duy quan trọng hơn bất kỳ một linh kiện đơn lẻ nào.
50. Liên hệ với Arduino/STM32 của bạn
Bạn có thể tạo một LINAC Safety Simulator bằng STM32.
Ví dụ phần cứng:
STM32
│
├── Button 1 → Door
├── Button 2 → Emergency
├── Button 3 → Gantry fault
├── Pot → Gantry position
├── Pot → MLC position
│
├── LED → READY
├── LED → BEAM
├── LED → FAULT
│
└── LCD 1602 → Status
51. FSM cho mô phỏng
Bạn có thể tạo:
IDLE
│
▼
CHECK
│
├──── fault ────► FAULT
│
▼
READY
│
▼
BEAM_ON
│
▼
BEAM_OFF
│
▼
READY
Emergency:
ANY STATE
│
▼
EMERGENCY
│
▼
BEAM OFF
Đây là một bài STM32 rất đáng làm.
52. Ví dụ LCD
Bình thường
┌────────────────┐
│ LINAC SIM │
│ READY B:OFF │
└────────────────┘
Beam đang chạy
┌────────────────┐
│ TREATMENT │
│ MU: 075 B:ON │
└────────────────┘
Door mở
┌────────────────┐
│ INTERLOCK │
│ DOOR OPEN │
└────────────────┘
Emergency
┌────────────────┐
│ EMERGENCY │
│ BEAM OFF │
└────────────────┘
Đây là mô phỏng giáo dục, không phải controller của máy xạ trị.
53. Một bài tập rất hay
Nếu muốn hiểu thật sâu, hãy thiết kế FSM:
STATE_IDLE
STATE_CHECK
STATE_READY
STATE_BEAM
STATE_COMPLETE
STATE_INTERLOCK
STATE_FAULT
STATE_EMERGENCY
và các input:
doorClosed
gantryOK
mlcOK
monitorOK
emergency
startCommand
Sau đó tạo bảng:
| State | Điều kiện | Next State |
|---|---|---|
| IDLE | Start | CHECK |
| CHECK | All OK | READY |
| CHECK | Fault | FAULT |
| READY | Start | BEAM |
| READY | Door open | INTERLOCK |
| BEAM | Complete | COMPLETE |
| BEAM | Fault | FAULT |
| ANY | Emergency | EMERGENCY |
Đây là cách học safety state machine cực kỳ trực quan.
🧠 54. Bài 9 – 15 từ khóa quan trọng
| Thuật ngữ | Ý nghĩa |
|---|---|
| Control System | Hệ thống điều khiển |
| Safety System | Hệ thống an toàn |
| Beam Permission | Điều kiện cho phép beam |
| Beam Inhibit | Ngăn beam phát/tiếp tục phát |
| Interlock | Cơ chế khóa khi điều kiện không phù hợp |
| Sensor | Cảm biến |
| Encoder | Phản hồi vị trí/chuyển động |
| Feedback | Tín hiệu phản hồi |
| Watchdog | Giám sát controller/software |
| Redundancy | Dự phòng |
| Fail-safe | Lỗi → trạng thái an toàn |
| Fault | Trạng thái bất thường/lỗi |
| Emergency Stop | Cơ cấu dừng khẩn cấp |
| State Machine | Máy trạng thái |
| Defense in Depth | Nhiều lớp bảo vệ |
🔑 55. Ba câu quan trọng nhất của Bài 9
①
Control system yêu cầu hành động; safety system quyết định hành động đó có được phép hay không.
②
LINAC không nên dựa vào một CPU, một sensor hoặc một đoạn software duy nhất để đảm bảo an toàn.
③
Khi có lỗi, tư duy quan trọng là Fail-Safe: hệ thống phải ưu tiên ngăn beam hoặc chuyển về trạng thái an toàn thay vì tiếp tục điều trị một cách không chắc chắn.
🔜 BÀI 10 – TỪ “BEAM ON” ĐẾN “DOSE ĐÃ ĐẾN ĐÚNG NƠI”
Bài tiếp theo chúng ta sẽ ghép Bài 7 + 8 + 9 thành một quy trình hoàn chỉnh:
TREATMENT PLAN
│
▼
MACHINE SETUP
│
┌──────┴──────┐
▼ ▼
GANTRY MLC
│ │
└──────┬──────┘
▼
SAFETY CHECK
│
▼
BEAM PERMISSION
│
▼
BEAM ON
│
▼
MONITOR CHAMBER
│
▼
MU COUNT
│
▼
BEAM OFF
│
▼
DELIVERY VERIFY
Sau đó chúng ta sẽ đi sâu vào một chủ đề cực kỳ quan trọng:
“Monitor Unit (MU) thực sự được sinh ra và đếm như thế nào?”
và phân biệt thật rõ:
MU → machine output → dose calibration → Gy → dose distribution → DVH
Đây sẽ là bước nối trực tiếp giữa điện tử điều khiển LINAC mà chúng ta vừa học với vật lý liều xạ trị.