Categories
Software Architecture

Một Số Nghiên Cứu Điển Hình 3: Robot Di Động

Robot di động

  • Hệ thống điều khiển phương tiện có người lái hoặc một phần có người lái
    • Xe hơi, tàu ngầm, phương tiện vũ trụ,…
  • Xây dựng phần mềm để điều khiển robot
    • Cảm biến bên ngoài và thiết bị truyền động
    • Thời gian thực
  • Đầu vào do cảm biến cung cấp
  • Điều khiển chuyển động
  • Lập kế hoạch con đường tương lai

Robot di động tiếp tục

  • Các yếu tố phức tạp
    • Các chướng ngại vật có thể chặn đường đi
    • Đầu vào cảm biến không hoàn hảo
    • Robot có thể hết điện
    • Độ chính xác khi di chuyển
    • Thao tác với vật liệu nguy hiểm
    • Các sự kiện không lường trước có thể dẫn đến cần phản ứng nhanh

Robot di động tiếp tục

  • Xem xét bốn (4) thiết kế kiến trúc
    • Vòng điều khiển
    • Thiết kế phân lớp
    • Hệ thống sự kiện
    • Bảng đen

Robot di động tiếp tục

  • Cân nhắc thiết kế
    • Yêu cầu 1: hành vi có chủ đích và phản ứng
      • Phối hợp các hành động của robot với phản ứng của môi trường
    • Yêu cầu 2: không chắc chắn
      • Robot cần phải hành động ngay cả khi nó có thông tin không đầy đủ và không đáng tin cậy
    • Yêu cầu 3: tính đến nguy hiểm
      • Khả năng chịu lỗi, an toàn, hiệu suất
    • Yêu cầu 4: tính linh hoạt
      • Phát triển ứng dụng yêu cầu thử nghiệm và cấu hình lại

Robot di động tiếp tục

  • Yêu cầu các loại khác nhau
    • Ứng dụng của chúng phụ thuộc vào độ phức tạp của công việc và khả năng dự đoán của môi trường
    • Ví dụ: robot đang hoạt động ở hành tinh khác => khả năng chịu lỗi tối quan trọng
      • Ít quan trọng hơn (FT) khi robot ở cơ sở bảo trì gần đó
  • Bốn yêu cầu hướng dẫn đánh giá bốn phương án kiến trúc

Giải pháp 1: vòng điều khiển

  • Một robot di động sử dụng mô hình vòng kín
    • Bộ điều khiển khởi tạo các hành động của robot và theo dõi hậu quả của chúng, điều chỉnh kế hoạch

Giải pháp 1 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 1: hành vi có chủ ý và phản ứng
      • + tính đơn giản của mô hình
      • – sự đơn giản của một vấn đề trong môi trường không thể đoán trước
        • Giả định ngầm: những thay đổi liên tục trong môi trường đòi hỏi phản ứng liên tục
        • Robot phải đối mặt với các sự kiện rời rạc
        • Chuyển đổi giữa các chế độ hành vi – làm thế nào để thay đổi giữa các chế độ?
      • Làm thế nào để phân tách phần mềm thành các thành phần hợp tác?

Giải pháp 1 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 2: sự không chắc chắn
      • – Quy trình thử-và-sai
    • Yêu cầu 3: tính đến những nguy hiểm
      • + sự đơn giản giúp dễ dàng sao chép
    • Yêu cầu 4: tính linh hoạt
      • + các thành phần chính (bộ giám sát, cảm biến, động cơ) tách biệt, độc lập, có thể thay thế

Giải pháp 1 tiếp tục

  • Tóm tắt:
    • Mô hình thích hợp cho người máy đơn giản
    • Chỉ có thể xử lý một số lượng nhỏ các sự kiện bên ngoài
    • Không thực sự dành cho việc phân rã các nhiệm vụ phức tạp

Giải pháp 2: Kiến trúc phân lớp

  • Tám cấp độ:
    • Cấp độ 1: Quy trình điều khiển robot (động cơ, khớp,…)
    • Cấp độ 2 & 3: đầu vào từ môi trường
      • Giải thích và tích hợp cảm biến (một so với một số cảm biến)
    • Cấp độ 4: mô hình của robot trong thế giới thực
    • Cấp độ 5 : điều hướng của rô bốt
    • Cấp độ 6 & 7: lập lịch và lập kế hoạch cho các hành động của rô bốt
      • Xử lý các vấn đề và lập kế hoạch lại: ở cấp độ 7
    • Cấp độ 8: giao diện người dùng và chức năng giám sát

Giải pháp 2 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 1: hành vi có chủ ý và phản ứng
      • + Nhiều thành phần hơn để ủy quyền nhiệm vụ cho
      • + Chỉ ra các mối quan tâm cần được giải quyết
        • Tích hợp cảm biến
      • + Xác định mức độ trừu tượng để hướng dẫn thiết kế
        • Điều khiển rô bốt so với điều hướng rô bốt
      • – Không phù hợp với dữ liệu thực tế và các mẫu luồng điều khiển
        • Không tuân theo kiến trúc lớp: để phản ứng nhanh, dữ liệu từ cảm biến trực tiếp đến xử lý sự cố ở mức 7, tương tự phản ứng lại
      • – Không tách biệt phân cấp dữ liệu (1-4) khỏi phân cấp điều khiển (1,5-8)

Giải pháp 2 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 2: sự không chắc chắn
      • + các lớp trừu tượng quản lý điều này
    • Yêu cầu 3: tính đến nguy hiểm
      • + được quản lý bởi cơ chế trừu tượng: dữ liệu và lệnh được phân tích từ các góc độ khác nhau
        • Khả năng chịu lỗi và an toàn bị động ok; an toàn hoạt động không ổn
    • Yêu cầu 4: tính linh hoạt
      • – sự phụ thuộc giữa các lớp là một trở ngại
      • – các mối quan hệ phức tạp giữa các lớp có thể trở nên khó quản lý

Giải pháp 2 tiếp tục

  • Tóm tắt:
    • Cung cấp khuôn khổ để tổ chức các thành phần
      • Chính xác về vai trò của các lớp
    • Các vấn đề khi thêm chi tiết ở cấp độ hiện thực
      • Mẫu giao tiếp trong rô bốt sẽ không tuân theo sơ đồ của kiến trúc

Giải pháp 3: hệ thống sự kiện

  • Kiến trúc điều khiển tác vụ
    • Dựa trên phân cấp nhiệm vụ
      • Cây tác vụ
      • Tác vụ mẹ khởi tạo tác vụ con
      • Nhà thiết kế phần mềm có thể xác định phụ thuộc thời gian giữa các tác vụ (ví dụ: A phải hoàn thành trước B)
      • Cấu hình lại động của cây nhiệm vụ tại thời gian chạy
    • Sử dụng lệnh gọi ngầm để phối hợp tương tác giữa các tác vụ
      • Các tác vụ giao tiếp bằng các thông báo đa hướng thông qua một máy chủ tin nhắn (chuyển hướng các tin nhắn đến các tác vụ đã đăng ký để xử lý chúng)

Giải pháp 3 tiếp tục

  • Lệnh gọi ngầm của TCA hỗ trợ:
    • Ngoại lệ: xử lý ngoại lệ ghi đè các tác vụ
      • Thay đổi chế độ xử lý
      • Có thể hủy bỏ hoặc thử lại các tác vụ
      • Phù hợp hơn để quản lý các sự kiện tự phát (ví dụ như lỗi)
    • Nghe lén: chặn tin nhắn bằng các tác vụ chồng lên trên
      • Kiểm tra độ an toàn của các lệnh gửi đi
    • Điều khiển: đọc thông tin và thực hiện các hành động
      • Các vấn đề về khả năng chịu lỗi khi sử dụng các tác nhân để giám sát hệ thống

Giải pháp 3 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 1: hành vi có chủ ý và phản ứng
      • + Tách hành động và phản ứng qua cây nhiệm vụ và ngoại lệ, nghe lén và giám sát
      • + đồng thời rõ ràng: nhiều hành động có thể tiến hành cùng một lúc và độc lập
        • – mặc dù trên thực tế bị giới hạn bởi máy chủ tin nhắn trung tâm
      • ⇒ – dựa vào một điểm kiểm soát trung tâm

Giải pháp 3 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 2: không chắc chắn
      • – không rõ ràng trong mô hình
        • Có thể thông qua cây nhiệm vụ và ngoại lệ
    • Yêu cầu 3: nguy hiểm
      • + ngoại lệ, nghe lén, giám sát
      • + khả năng chịu lỗi do dự phòng
        • Nhiều trình xử lý được đăng ký cho cùng một tín hiệu, cái này bị lỗi thì cái khác tiếp quản
        • Nhiều lần xuất hiện cùng một yêu cầu: đồng thời
    • Yêu cầu 4: tính linh hoạt
      • + lệnh gọi ngầm cho phép phát triển và thay thế gia tăng các thành phần
        • Thường đủ để đăng ký trình xử lý mới trong máy chủ trung tâm

Giải pháp 3 tiếp tục

  • Tóm tắt:
    • TCA cung cấp một bộ tính năng toàn diện để điều phối các nhiệm vụ
    • Thích hợp cho các dự án rô bốt phức tạp

Giải pháp 4: bảng đen

  • Dựa trên các thành phần sau:
    • Thuyền trưởng (Captain): người giám sát tổng thể
    • Người điều hướng bản đồ (Map navigator): người lập kế hoạch đường đi cấp cao
    • Người canh gác (Lookout): giám sát môi trường
    • Phi công (Pilot): người lập kế hoạch đường đi cấp thấp và bộ điều khiển chuyển động
    • Hệ thống con nhận thức (Perception subsystem): đầu vào thô từ cảm biến và sự tích hợp của nó với một cách diễn giải

Giải pháp 4 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 1: hành vi có chủ ý và phản ứng
      • + các thành phần tương tác thông qua kho lưu trữ được chia sẻ
      • – luồng điều khiển phải được cưỡng chế để phù hợp với cơ chế cơ sở dữ liệu
        • Các thành phần không giao tiếp trực tiếp
    • Yêu cầu 2: sự không chắc chắn
      • + bảng đen cũng là phương tiện để giải quyết xung đột và không chắc chắn
        • Tất cả dữ liệu có sẵn trong cơ sở dữ liệu

Giải pháp 4 tiếp

  • Bốn yêu cầu?
    • Yêu cầu 3: tính đến các mối nguy hiểm
      • + giao tiếp qua dịch vụ trung tâm, cơ sở dữ liệu
        • Xử lý ngoại lệ, nghe lén, giám sát có thể được thực hiện bằng cách thêm các mô-đun theo dõi cơ sở dữ liệu để tìm các dấu hiệu nhất định của các tình huống có vấn đề
    • Yêu cầu 4: tính linh hoạt
      • + Hỗ trợ đồng thời
      • + Tách người gửi khỏi người nhận
        • Tạo điều kiện bảo trì

Giải pháp 4 tiếp tục

  • Tóm tắt:
    • Kiến trúc có khả năng mô hình hóa sự hợp tác của các nhiệm vụ
      • Phối hợp
      • Giải quyết sự không chắc chắn
    • Ít mạnh hơn TCA một chút
  • Không phải là khả năng duy nhất cho người máy…
    • Ngoài ra tồn tại kiến trúc lai

Comparison

Control loopLayersImpl. invocationBlackboard
Task coordination+ –+++
Dealing with uncertainty+ –+ –+
Fault tolerance+ –+ –+++
Safety+ –+ –+++
Performance+ –+ –+++
Flexibility+ –++

Điểm quan trọng của ngày hôm nay

  • Cần có một bộ sưu tập các kiểu kiến trúc cơ bản
  • Các nghiên cứu điển hình nhỏ hữu ích cho mục đích minh họa
  • Các ý tưởng tương tự (khá cơ bản) sẽ quay trở lại trong lĩnh vực của chúng ta
    • Dropbox
    • Điện toán đám mây
    • Wikipedia

Leave a Reply

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