Skip to content

Công nghệ 9 giây

“Website hướng dẫn, thử nghiệm và giải thích công nghệ theo cách dễ hiểu cho mọi người.”

Menu
  • Home
  • Công nghệ
  • STM32
  • ESP32
  • Altium Desinger
  • Kiến thức điện máy
Menu

📘 BÀI 9 – “BỘ NÃO” CỦA LINAC

Posted on August 16, 2026 by congnghe9s

📘 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ị.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Bạn có thể hướng dẫn tôi quy trình sửa chữa một mainboard laptop cũng như mainboard của máy tính để bàn không?
  • Có những mức nguồn DC nào trên một bo mạch mainboard laptop?Kỹ thuật đốt dòng để kiểm tra nguồn laptop được thực hiện như thế nào?
  • bài tiếp theo hợp lý là: BÀI 63 – SENSOR FUSION THỰC CHIẾN: ENCODER + IMU MPU6050 + EKF + ODOMETRY X,Y,θ TRÊN STM32F103
  • BÀI 62 – EKF (EXTENDED KALMAN FILTER) CHO ROBOT 2 BÁNH: FUSION ENCODER + IMU + ƯỚC LƯỢNG X, Y, θ, V, ω
  • BÀI 61 – KALMAN FILTER CHO ENCODER + IMU: ƯỚC LƯỢNG TỐC ĐỘ, GÓC θ VÀ SENSOR FUSION

Recent Comments

No comments to show.

Archives

  • September 2026
  • August 2026
  • July 2026
  • June 2026
  • May 2026
  • February 2026

Categories

  • Altium Desinger
  • Công nghệ
  • ESP32
  • Khác
  • Kiến thức điện máy
  • STM32
Live 3D Globes Visitor
©2026 Công nghệ 9 giây | Design: Newspaperly WordPress Theme